POV-Ray : Newsgroups : povray.programming : Object oriented POV scene language? : Re: Object oriented POV scene language? Server Time
28 Jul 2024 18:21:11 EDT (-0400)
  Re: Object oriented POV scene language?  
From: Disnel
Date: 28 Jul 2000 05:46:46
Message: <39815686.AA9BAAB5@itam.cas.cz>
Chris Huff wrote:
> 
> In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz>
> wrote:
> 
> > But what are POV #declares? They can be taken as references, I think.
> 
> I suppose they could be considered references...
> You could create basic "types" by making certain base objects to
> inherit/copy from, just like you do in some of the include
> files(shapes.inc, for example). Members would be copied as well. In
> other words, objects inherit from objects, not from object types.
> My idea doesn't separate types of objects and actual objects, like C++,
> but it should work, and might be much easier for people to learn.
> Besides, I don't see any simpler way of adding OOP to POV-Script.

I also think, that C++ style with class declaration and using
new after is inappropriate for POV language. Better will be
true OO style: each object can contain each object, messages
sent to object are also objects and result of message sent to object is
also object.

> 
> > You are right with virtual methods, all would behave "virtual"
> 
> I don't see how they couldn't, since POV is interpreted all in one pass,
> and doesn't have separate compile-link-run stages. That, and the way
> it's "types" are done...

Sure, they can.

> 
> > For example I have two spheres and my new object, which connects
> > these two spheres with cylinder. When one sphere was changed during
> > animation, my connecting object need to be notified about it.
> > Where it contains only copies of sphere, it knows nothing about
> > change.
> 
> I still don't see the problem...have one sphere be changed with a member
> macro, which calls member macros of the other sphere and the linking
> cylinder. When one changes, the other two will be updated automatically.
> The main sphere is updated every frame of the animation, and all three
> are stored in persistent variables, say Sphere1, Cylinder, and Sphere2.
> After processing is done, copies of them are placed in the scene, like
> this:
> Sphere1.Update(clock);
> 
> object {Sphere1}
> object {Cylinder}
> object {Sphere2}

Yes, it will work, but it will waste memory and CPU time,
its no problem with sphere but if you want make descendant from 50MB
tree, it will be very unfortunate.
Second, it will be unnecessary compilcated to use.

> 
> > > If you mean adding members to an existing variable, then don't do that!
> > > It would be like trying to add variables and methods to a C++ class.
> > > Just make a new object from that one, which has the additional members
> > > you need.
> >
> > I don't mean anything else.
> 
> Just make a new variable/class with the new members, and using the same
> name as the parent object...like this:
> #declare Foo = object {...}
> #declare Foo = object {Foo ...new members...}
> Where is the problem? You don't need to be able to add variables or
> functionality to an existing object, just create a new one derived from
> the original. What do you think inheritance is for?

Maybe.

> 
> > Here we don't understand: you are thinking about object oriented
> > preprocesor and I'am thinking about object oriented scene during
> > rendering and animation, I'am right?
> 
> No processing of the scene file is done during rendering...the scene
> *has* to remain static during that stage, and it wouldn't make sense
> otherwise. It makes sense to only modify objects which you have in
> dynamic form, as a variable. As for animation, the scene is reprocessed
> before every frame. You can keep variables from one frame to the next,
> what is wrong with modifying those and rebuilding the scene each frame?

Sure, scene should remain static during rendering, you are right ;-).
But rebuilding whole scene for each frame is once more wasting
of CPU time, is some cases, chance to use objects from previsous
scene with only slight modifications can improve rendering time.
For example smoothing height field, tree generation .... It can be
done once for whole animation.

> 
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.